Ingeniería del software ? Programación del Software
Ingeniería de sistemas
Campo interdisciplinario de la ingeniería que se centra en cómo los proyectos complejos de ingeniería deben ser diseñados y gestionados;
Se ocupa de todos los aspectos del desarrollo del Sistema informático;
Identifica las funciones de hardware, software, personas, bases de datos y otros elementos del Sistema que participan en ese Sistema que se va a desarrollar.
Ingeniería del software
Es una parte de la ingeniería de sistemas a nivel de usuario
Decir los aspectos prácticos del desarrollo y distribución de software útil.
11
Aspectos de gestión económica y de SE
La produccion de software = mantenimiento + desarrollo (evolución)
Costes de mantenimiento > 60% de todos los costs de desarrollo
20% correctivo
30% adaptativo
50% perfectivo
Desarrollo más rápido no siempre es preferible
Mayores costos por adelantado pueden sufragar los costos aguas abajo.
Software mal diseñado / implementado es un factor de coste crítico.
12
Componentes típicos de software embebido
13 of
13
Casi idéntico a los sistemas generales informáticos
Software de aplicación
Controlador de dispositivo
Componentes típicos de software embebido (cont.)
14 of
14
Middleware – ¿Qué es?
Middleware es un software que ha sido extraído de la capa de aplicación por una variedad de razones. Una de las razones es que ya puede ser incluido como parte del paquete del Sistema operativo fuera de la plataforma OS.
Otras razones para eliminarlo de la capa de aplicación son: permitir la reutilización en otras aplicaciones, para reducir costes o el tiempo de desarrollo mediante la compra off-the-shelf a través de un proveedor de terceros, o para simplificar el código de la aplicación.
En los términos más generales, el software middleware es el software del Sistema que no es el núcleo OS del Sistema operativo, controladores de dispositivos, o software de aplicación.
A continuación se muestra el middleware en el Modelo de Sistemas Embebidos (ver más en http://www.eetimes.com/document.asp?doc_id=1276764
(Gp:) Bus de datos
(Gp:) Memoria
De datos
(Gp:) Memoriade programa
(Gp:) interrupciones
(Gp:) Digital o/p
(Gp:) Analog o/p
(Gp:) Digital i/p
(Gp:) Analog i/p
(Gp:) ENTRADAS
(Gp:) SALIDAS
(Gp:) Links A otros sistemas
(Gp:) Interfaz de Usuario
(Gp:) Bus de direcciones
(Gp:) CPU
(Gp:) AnalógicoFront End
(Gp:) Digitali/p Ports
(Gp:) Módulos Interfaz Usuario
(Gp:) Digitalo/p Puertos
(Gp:) D/A,
Aislamiento
(Gp:) Comms:
ASC, SSC,USB, IIC,
IrDA, etc.
(Gp:) Soporte:
Temporizador de guarda
15 of
15
Desarrollo del ciclo de vida de software. Modelo Cascada
Requisitos
Diseño
Implementación
Integración
Validación
Despliegue
16
Desarrollo de ciclo de vida de software. Modelo espiral
17
Determinar objetivos, alternativas, limitaciones
Evaluar alternativas, identificar, solucionar riesgos, desarrollar prototipos
Planificar las siguientes fases
Desarrollar, verificar los productos del siguiente nivel
18
Hardware-Software Co-Diseño de Sistemas Embebidos
El Software que basa su funcionalidad en los productos embebidos de hoy causan retrasos en la completitud de los proyectos si se tiene que esperar al prototipo de hardware para empezar el desarrollo de software y su depuración.
Diseño concurrente y verificación de hardware y software es una tendencia que reduce el tiempo de lanzamiento al mercado.
(ver más en [4, 5] )
Requisitos
Problema de definición ? Especificación de requisitos
Determinar exactamente qué quiere el cliente y el usuario.
Desarrollar un contrato con el cliente
Especificar qué va a hacer el software de producto
Dificultades
El cliente solicita el producto que no es adecuado
El cliente no conoce el software
Las especificaciones son ambiguas, inconsistentes e incompletas.
19
Arquitectura/Diseño
Especificación de requisitos? Arquitectura/Diseño
Arquitectura: descomponer el software en módulos con interfaces
diseño: desarrollo de las especificaciones del módulo (algoritmos, tipos de datos)
Mantener un registro de las decisiones de diseño y trazabilidad
Especifica cómo el product de software hace sus tareas.
Dificultades
La falta de comunicación entre los diseñadores de módulos
El diseño puede ser incoherente, incompleto y ambiguo.
20
Arquitectura vs. Diseño[Perry & Wolf 1992]
La Arquitectura tiene que ver con la selección de los elementos arquitectónicos, sus interacciones y las limitaciones de los elementos y sus interacciones necesarias para proporcionar un marco en el que se cumplan los requisites y que sirva como base para el diseño.
El diseño se ocupa de la modularización y las interfaces detalladas de los elementos de diseño, sus algoritmos y procedimientos, y los tipos de datos necesarios para apoyar la arquitectura y para satisfacer los requisitos.
21
Implementación e Integración
Diseño ? Implementación
Implementar módulos; verificar que cumplen con sus especificaciones
Combinar módulos de acuerdo con el diseño
Especifica cómo el product de software realiza sus tareas
Dificultades
Errores de interacción del módulo
Orden de integración puede influir en la calidad y la productividad
22
Desarrollo basado en componentes
Desarrollar components generalmente aplicables de un tamaño razonable y reutilizarlos a través de sistemas.
Asegurarse de que son adaptables a los diferentes contextos
Extender la idea más allá del código en el desarrollo de otros artefactos
Pregunta: ¿Qué viene primero?
Integración, a continuación despliegue
Despliegue, a continuación integración
23
Diferentes componentes
Software de terceros “piezas”
Los Plug-ins de efectos/ complementos
Applets
Frameworks
Sistemas abiertos
Infraestructuras de objetos distribuidos.
Documentos compuestos
Los sistemas heredados
24
Verificación y validación
¿Qué es verificación y validación?
VerificaciónLa verificación confirma que el trabajo de los productos reflejan adecuadamente los requisitos prescritos para los mismos. En otras palabras, la verificación asegura que “el product se ha construido correctamente”
ValidaciónLa validación confirma que el product, según lo previsto, cumplirá con su uso previsto. En otras palabras, la validación asegura que “has construido lo correcto”.
25
Verificación y validación ¿Cómo actúa?
26
Modelo de desarrollo de sistema
Calidades de Software
Exactitud
Óptima calidad
establecido w.r.t., la especificación de los requisitos
absoluta
Confiabilidad
Propiedad estadística
Probabilidad de que el software funcionará como se esperaba durante un período de tiempo dado
Relativo
Robustez
Comportamiento “razonable” en circunstancias imprevistas
subjectiva
Un requisito especificado es un problema de la corrección;un requisito no especificado es un problema de robustez.
27
Usabilidad
Capacidad de que los usuarios finales puedan utilizer fácilmente el software
Extremadamente subjetivo.
Comprensibilidad
Capacidad de los desarrolladores a entender fácilmente los artefactos producidos
La calidad interna del producto
subjetivo
Verificabilidad
La facilidad de establecer las propiedades deseadas
Realizado por análisis formal o pruebas
Calidad interna
Rendimiento
Equiparado con la eficiencia
Evaluables mediante la medición, el análisis y simulación.
Calidades de software (cont.)
28
Desarrollo
Posibilidad de añadir o modificar la funcionalidad
Aborda el mantenimiento adaptativo y perfectivo.
problema: La evolución de la implementación es muy fácil
La evolución debe comenzar en los requisitos o en el diseño
Reutilización
Capacidad de construir un Nuevo software a partir de piezas existentes
Debe ser planificado
Ocurre a todos los niveles: desde la gente a los procesos, desde los requisitos hasta el código.
Interoperabilidad
Capacidad de los (sub)sistemas de software a cooperar con los demás
Fácilmente integrable en sistemas más grandes.
Técnicas communes que incluyen APIs, protocolos plug-in, etc.
Calidades de Software (cont.)
29
Calidad de software (cont.)
Escalabilidad
Capacidad de un Sistema de software para crecer en tamaño, mientras que mantiene sus propiedades y cualidades.
Asume el mantenimiento y la capacidad de evolucionar
Objetivo de desarrollo basado en componentes
Heterogeneidad
Capacidad de componer un Sistema de piezas desarrolladas en varios lenguajes de programación, en multiples plataformas, por multiples desarrolladores, etc.
Necesario para la reutilización.
Objetivo de desarrollo basado en componentes
Portabilidad
Capacidad de ejecución en entornos nuevos con un mínimo esfuerzo.
Puede ser planeado mediante el aislamiento de componentes dependientes del entorno.
Necesarios para la aparición de los sistemas altamente distribuidos (por ejemplo, Internet)
30
 Página anterior | Volver al principio del trabajo | Página siguiente  |